<?php

1->pom依赖
   分布式项目中一般模块很多，抽象一层'spring-cloud-项目名'来管理子项目的公共的依赖。
   为了项目的正确运行，必须让所有的子项目使用依赖项的统一版本，确保应用的各个项目的依赖项和版本一致，
   才能保证测试的和发布的是相同的结果。

   在我们项目顶层的POM文件中，'dependencyManagement'元素。通过它元素来管理jar包的版本，
   让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，
   然后它就会使用在这个dependencyManagement元素中指定的版本号。

   <dependencyManagement>主要管理版本，对于子类继承同一个父类是很有用的，集中管理依赖版本不添加依赖关系，对于其中定义的版本，子pom不一定要继承父pom所定义的版本
   <dependencies>中的jar直接加到项目中，管理的是依赖关系（如果有父pom,子pom,则子pom中只能被动接受父类的版本）


2->分布式拆分————模块
   -) '规则'
       pom拆分: 不要引入多余的依赖，避免产生jar包冲突 (单个微服务只对'自身pom负责!')
       微服务模块拆分: 粒度适中
       公共组件剥离: 公共Utils之类
       平台中间件剥离: 注册中心，配置中心之类.(不掺杂业务!)

   -) '结构'
       common: 公共组件, 公共依赖项
       domain: 各个微服务模块
       platform: 平台组件

   -) '技巧'
       1->pom
          构建'父pom'时, 使用'版本控制', 然后'子模块'引用时就可以'不用担心版本'.
          <dependencyManagement>
              <dependencies>
                  ...
              </dependencies>
          </dependencyManagement>

       2->Mapper
          定义MyMapper<T>继Mapper<T>，MySqlMapper<T>，从而实现各自的业务Mapper继承MyMapper即可！

       3->模块划分
          定义各个微服务模块，其中commin模块，可以分为: xm-cloud-common（自定义工具类，MyMapper<T>）
          xm-cloud-shared-pojo（实体类，枚举，统一返回，pom-pagehelper）

       4->实用性!!!
          pojo__vo_dto:
          单独创建模块进行存放, 记得实现序列化 (后期如果过多的话, 可以根据各自业务模块进行拆分) - jar
          好处: 服务间调用创建'feign'的话, 也不用为'返回值'创建新的pojo!

          service_interface:
          各个模块各自归建! 作为一个微服务模块对外提供, 引入[pojo] - jar
          好处: 实现接口的统一控制!

          service_imp——controller:
          真实业务逻辑与接口 引入[service_interface], 实现接口进行后续业务操作!!!
          好处: 更加关注业务逻辑, 将重心放在业务层!


3->分布式拆分————结构
   -) '传统模式'
       我们做微服务拆分时, 一般按'业务模块'进行分层
       'user模块'
       . controller (文件夹-W)
       . service    (W)
       . mapper     (W)
       . pojo       (W)
       注意: 这里单模块下创建'文件夹', 而每个大模块作为'一个微服务', 对外提供.

   -) '领域模型'
       而此种分层结构是, '每个功能模块'下的'每个文件夹'作为一个微服务.
       'user模块'
       . controller (微服务模块-M)
       . service    (M)
       . mapper     (M)
       . pojo       (M)
